Serverless Meetup Tokyo #4 レポート #serverlesstokyo

臼田佳祐

2017.08.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

Serverless Meetup Tokyo #4が開催されましたのでレポート致します。

セッションレポート

体育会系サーバーレス：汗、友情、勝利、テニス

竹原竜児氏 (ソニー)

Smart Tennis Lesson(STL)で利用しているサーバレスについてのお話
STLとは
- 2017 3月より全国導入
- ルネサンスにて導入
Serverlessへの期待と疑問
- 期待
  - 自社の問題領域の解決に集中できる、早くリリースできる
  - NWレイヤまでの保守運用、脆弱性対応などを限りなく0に近づける
  - インフラコストが安くなる
  - SWアーキテクチャ上　凝縮度が高い、結合度低い設計に誘導される
- 疑問
  - SQLベースのB2B2Cという固めの案件にうまくServerlessで対応できるのか？
今日の発表内容
- SQL DBを使ったサービスへのServerless導入が成功するまでの重要アクションとTipsを共有
- 汗
  - Serverlessに適合させたテスト、運用！
- 友情
  - 既存SQLスキルをデータ連係、グループアクセス制御
- 勝利
  - パフォーマンス向上
STL System構成
- テニスコートにIoT機器
  - テニスネットのポールにカメラを設定
  - リアルタイムにストリーミングして動きを確認
  - テニスのグリップにつけるセンサーでボールの当たった位置、スイングスピードなどを取得
  - Bluetoothで送信している
- AWS側
  - API Gatewayで取得してLambdaで処理、RDSに格納
  - 家に帰った後も生徒さんが確認できるようにフロントも用意

汗編

ServerlessでもTest First! CI整備に汗をかく
- Nodeのテストツールであるmochaを利用
- LocalテストにはAPI Gatewayからのデータをダミーで渡して、Local, Remoteで同じテストコードで実施
- 判定はistanbulを利用, C0/C1共に80%以上にしている
- CIはapexを利用
  - Serverless Frameworkと違いエイリアスに対応している
- API GatewayでCustom Domain Switchで切り替える
- Sig4Clientを入れて認証
Lambda運用監視のお手軽構築テンプレを作る
- 標準のLambdaログだと見にくいので独自のLoggerで必要項目を必ず出力している
  - リソースパスやログレベルなどを埋め込んでおく
  - MetricFilters, Alarm, SNSはセットで構築できるようにCloudFormationテンプレートを用意
Serverless時代になってテストと運用設計スキルはより重要になってきている
- テストと運用の提携をプロジェクト初期に決めておいてテストを実行する

友情編

ServerlesにSQL(Aurora)を組み合わせることについて
- いくらでもフロントがScaleするのにRDBはlimitが存在する
- VPC Lambdaを使わないといけない
B2Bでのデータ連係で既存SQLスキルフル活用
- 主要な要件はSQLで完結、LambdaはSQL連続発行とログ出力だけ
- AuroraへのCSV->テーブルの取り込みはLOAD DATA FRO< S3文
認可、権限コントロールもCognito + SQLで強力かつ柔軟
- 効力に守るところはCognito, API GWに任せる
  - DoSが来てもLambdaまで負荷は来ない
- 柔軟に表現したいところはSQLの関連としてチェックする
  - 構造化された関連をたどるものはSQLなら1行で自然に表現

勝利編

VPC Lambda
- Aurora(RDS)を使うため必須
- API Callからデータにたどり着くまで長い
- Localでは100ms程度だがAPI経由だと1秒以上応答がかかる
- 10秒以上かかるときもある
VPC Lambda ENIの仕組みを知る
- 分析にはCloudTrail
- Create/Delete NetworkInterfaceを調べた
- 対策としては定期的にENI, Lambdaを暖気
Lambda初期化処理の場所にご注意を
- まだ1秒以上リクエストにかかっている
- 分析にはAPI GWのlateny logとLambda開始終了のタイムスタンプ
- 原因はORマッパーの初期化
- 対策は一度初期化したORマッパーをグローバルに保持するように変更
- 通信時間も含めて900-1200msから200-500ms程度での応答を達成
Lambda対策 Tipsメモリけちるべからず
- メモリを上げるとインスタンスタイプが上がるのでCPUに依存したものも早くなる

まとめ

既存のベストプラクティスをServerlessに適用させることが重要！

感想

一般的にはLambdaとRDSを選択することは難しいですが、とてもいい成功事例だと感じました。

ベストプラクティスを忘れずに実践していきたいですね。

Test Driven Development For Lambda

堀家隆宏氏 (デジタルキューブ)

資料
Serverless Frameworkの日本語フォーラムを運営している
Lambdaを使ったテストについて話す
なぜテストをするか
- 継続的に開発を行うプロジェクトやプロダクトん質を保ちつつ改善のためのソースコードの変更を効率良く行うための土台を作る
  - 例えば大きなプロジェクトだと多数のPull Requestが来る
  - 人でさばくことはできないのでテストを作って自動化していく
- イベントドリブンで作ると疎結合なマイクロサービス群を統合してテストをするという、今までにあまり馴染みのないテストの考え方が必要になった
- アーキテクチャの特性上ソースコードの品質がシステム自体の品質にダイレクトに影響をおよぼすため、なんとなくでは済まされない部分が大きくなってきた
  - インフラのせいにはできない！
イベントドリブンアーキテクチャのテスト戦略ってどんなの？
- 全体のインテグレーションテストとLambdaのユニットテストを行う
インテグレーションテストのポイント
- Serverless FrameworkやSAM等のデプロイツールを使いアーキテクチャを定義
- デプロイ、テストの実施、削除の流れをコード化する
- API GWのインテグレーションテストの例
ユニットテストの流れ
- AWS APIへの接続をモックやLocalStackといった仮の環境で置き換える
- AWSリソースはテスト外として単純に処理の流れやエラー処理の分岐などをプログラムしようのテストに重点を置く
- AWS APIの存在を意識する以外はいわゆる通常のユニットテスト
- モックを作る例 AWS Lambdaのユニットテストのベストプラクティス(Node.js)
これらのテストを組み合わせてどのようにTest Drivenにするか
- まずはインテグレーションテストを書く
  - 逆にユニットテストからにするとモックの値の設計などができないので注意
- Lambdaは正常系のみをざっくり通りレベルでいい
- 次にLambda内のエラー処理について整理してユニットテストとプログラムをブラッシュアップ
- 最後にインテグレーションテストとユニットテストが通る事を確認して完成
まとめ
- インテグレーションテストを行なってマイクロサービス全体を網羅するテストを行う
- ユニットテストはAWS APIに接続せずに純粋なプログラムの振る舞いのみ
- 開発の際はまずインテグレーションテストを書く
- 実践で使えるためには自分でテストを買い手体に覚えさせましょう

感想

具体的なテストの手法についても参考文献とともに解説されていて参考になります！

上記URLのgithubやqitaもよく確認したいですね！

Azure Cosmos DB + App Serviceの良い関係（仮）

三宅和之氏 (ゼンアーキテクツ)

開発事例について
- 富士フィルム「IMAGE WORKS」
- サーバ(VM)は一切使わない
規模
- 登録データ1TB/day
- ユーザ4万人
フルPaaS構成での開発、リリース
- PoCから開発まで期間6ヶ月
Keyとなったテクノロジー
- Cosmos DB (DocumentDB API)
- Azure App Service (Functions, Webjobs)
- NoOpsがコンセプト
Azure Cosmos DB
- NoSQLデータベース基盤
- 低レイテンシ(SLA付き)
  - 読み取り10ms以下、書き込み15ms以下(90%タイル)
- スケール
- グローバル分散
Azure App Service
- アプリケーション実行基盤
  - ほぼNoOps
- HotPoolベース
  - いつも温まっている、暖気がいらない
- 複数のサービス形態に対応
- 付加機能が割りと充実
アーキテクチャ設計のポイント
- バッチ処理の設計
  - オンプレミスとの動機処理はQLL(queue-based load leveling) + Scale-outで実装
  - キューの待ち行列が指定した長さを超えたらスケールアウト
  - Cosmos DBはスパイクに対応できる予約ノードを利用できる
  - Queue + Funcetionsのいいところ
    - ループが一切なくなるのでここのプログラムが短くなる
    - インフラの機能だけで処理量を調整できる
- フロントエンド設計
  - SAPを利用
  - 機能毎に使うサービスを分ける
- グローバル分散・DR
  - Traffic Managerを活用
    - DNSレベルでエンドポイントをルーティング
  - グローバル分散NoSQLデータベース・サービス
「高弾力性設計」実現のために考慮したこと
- エンドポイントは軽い処理のみ
- 非同期分散処理が基本
- Workerの粒度は小さく
- 処理はStateless
- 接続もStateless
- Stateはデータストアで管理
Design principles for Azure applications

感想

Azureでも楽しくServerlessできそうなお話でした。

Design principles for Azure applicationsは一般的にも活用できる内容のようなので、必見ですね。

The Architecture of Serverless React SPA

池内孝啓氏（slideship）

資料
slideshipとは
プレゼンテーションのスライドをwebで作れる
- markdown対応
- syntax highlightしてくれる
Principal
- クラウドネイティブ
- Serverlessがいい
- URIに神が宿っている
- State-less
- サーバはJSONを返す
- HTMLのクライアントサイドはSPA
- CDN使おう
Infra
- CF, S3
- ALB, EB, Lambda
- Aurora
Appications
- EBはGo
- CloudFrontではRESTとSPAの2つを処理
環境はバージニアに乗っている
新しいものが一番早く使えるから
レイテンシーは気になることはあるが基本はCFが利用できるのである程度緩和できている
God is in the URI
- URLの見た目にこだわっている
DEMO
- webから編集できる
- スライドの入れ替えもドラッグ・アンド・ドロップで出来る
- P○werP○intみたい！
- レイテンシーは気にならない
Alt-Serverside Rendering for OGP Optimization
- サーチエンジンのオプティマイズの闇
- Googleの検索エンジンが対応していなくてうまく動いてくれなかったが最近はJSを評価してくれている
- 動的なOGPを読んでくれない(Twitter, FB, Slack等)
- Server Side Rendering(SSR)
  - Serverlessじゃなくなるので採用したくない
- Prerendering
  - アクセス権限の問題などで懸念点が残る
- 自前で実装した
- Prepared Multiple Entry-point
  - という名前にした
  - プリ生成したものをS3に置いておく
  - OGPについても記載しておく
  - コンテンツ本体はJSで取ってくる、あくまでOGP対応のため

感想

シンプルで面白いwebスライドのサービスですね。

Markdownで書けるのも楽しいですね！

Serverless Application with Chalice

西谷圭介氏 (AWS)

Chaliceの紹介
- AWSが提供するオープンソースのサーバーレスアプリケーション開発フレームワーク
- Python向け
- 7/31にGAしたばかり
- Chaliceというコマンドラインも提供
- コードの自動生成
- IAMポリシーも自動生成
APIバックエンドの構築
- デコレータにより作成したファンクションとAPI GatewayのAPIを簡単にルーティング
- chalice deploy
  - デプロイ用のコマンド
  - 依存関係の解決なども行う
- シンプルなファンクションも書ける
- Scheduled Event
  - スケジュール実行も書ける
- Automatic Policy Generation
  - コードをスキャンしてAWSコールを検出
  - 必要最低限のIAMポリシーを自動生成
  - 自分でIAMポリシーを当てることも可能
- CI/CD
  - CIパイプラインの作成
  - Code兄弟を使ったパイプライン
  - 実際にはCFnテンプレートで動作

感想

シンプルで強力なツールなので、Chaliceすぐに検証したいです！

１日１億イベントを捌くサーバレスアーキテクチャ

なりたけいすけ氏 (CyberAgent)

アメブロのエンジニア
AmebaにServerlessを導入した話
アメーバブログ公式ジャンルを公開した
- ジャンルごとにランキング
Lambda中心にサーバレスで構築
様々なところからAPIが呼ばれるので、どれだけリクエストが来ても耐えれるようにしたかった
一つのページから5つのAPIリクエストがあったりする
大量のEC2は絶対管理したくないのでLambdaを利用した
Serverless Frameworkを利用
一応載せ替えても動くようにnode.jsの中身を構築した
1億/1day
- スロットリングだけ気をつけていれば問題ない
HealthcheckもLambdaからSlack通知
DynamoDBのアラートもLambdaで自動調整
- 公式でAutoScale対応したから今はいらないかも
レポートもLambdaからSlack
BatchをDynamoに適用
S3チェック
Athenaも使ってレポートしている
Serverlessのつまづき
- Lambdaのストレージ要件を超えることがあった
  - 75GB上限
  - Lambdaのバージョン情報が影響していた
  - デプロイ中に古いバージョンを上書きしたのでON
  - デプロイ完了したら古いバージョンを消すようにした
- リソース上限を超える
  - 200リソースを超えるので役割毎作る
- TeraFormと被る
  - EC2はTeraform
  - Serverless FrameworkはLambda管理
- サービスが一杯で大変
  - 頑張って覚える
- Bookkey
  - ディスプレイの前を通ると風や音がなる
メリット
- どこかが壊れても大丈夫
- サーバ管理しなくていいのが楽！

インフラエンジニアがRails周りで頑張る

高橋恒樹氏

標準的なRalis環境周りで奮闘した
Deploy・運用一般
- Slackからデプロイ
- Slackから管理サーバのIP制限を解放
  - 塞ぐのはCloudWatch Eventで定期的に実行
中国ユーザ対応
- 見えない壁でCloudFrontが効かない
- 中国リージョンでS3を置く
まとめ
- バリバリサーバアプリケーションの運用を担当している
- エンドユーザの目に触れる形でもデビューしたい

flowtypeStepFunction

尾崎耕多氏 (ChatWork)

最近Lambdaの作り方が変わった
- Step Functionsで個別のFunctionに切り分けれるようになった
- 環境変数の対応
- SAMやその他のフレームワーク
1つのLambda Functionが小さくなってきた
一つの処理だけ行って結果を返すLambdaを使いまわせる
こうなると、ユニットテストはいるのだろうか？
答えはflowtype
- node.jsに型をつけれる
- 型によって
  - コードが正しいこと
  - Eventのプロパティが正しいこと
  - PutObjectが正しく呼ばれること
  - callbackには結果が渡されること
まとめ
- flowtype最高！！

サーバーレスの夢と現実

田中宏幸氏 (INFASパブリケーションズ)

2016年9月からサーバーレス
ユーザはCFとAPI GatewayとS3を見ている
SSRはLambda
WordPressからAurora
LambdaもAurora
Auroraは危険？
- 最大接続数
  - r3.xlarge * 3 = 6000
- ENI生成時間
  - RDSへのIAM認証接続で解決
  - いまはhot standbyしている
- latency
  - 保証されていない
- latencyも安全にしたい
- でも、WPのDBをDynamoにはできない
- jsonにするところまでAuroraでjsonにしてからDynamoに入れる
- DynamoじゃなくてCosmosのほうがいいのでは？
- LambdaからCosmos呼んだらいいのでは？
- これってベストプラクティスなのかな？
とりあえずAuroraと向き合う
- CFのCashes TTL = 86400
- WPで更新するとLambdaでキャッシュを消す
ブログはじめました